笔者一直在思考 Shiro 如何通过 SecurityUtils 拿到当前用户。原来是对于每个 HTTP 请求，在 Java 中都会开启一个线程进行处理，这个线程内就存放了当前的请求与请求信息，Shiro 通过当前线程，就可以拿到对应的 HTTP 请求，从而拿到当前用户。

进一步考虑，Spring Boot 是如何实现这一过程的呢？Spring Boot 如何为每个请求分配线程，在线程中注入请求信息，又如何通过线程取出请求呢？

源码：

Exposes the previously bound RequestAttributes instance, if any. * Falls back to the current JSF FacesContext, if any. * @return the RequestAttributes currently bound to the thread * @throws IllegalStateException if no RequestAttributes object * is bound to the current thread * @see #setRequestAttributes * @see ServletRequestAttributes * @see FacesRequestAttributes * @see javax.faces.context.FacesContext#getCurrentInstance() */ public static RequestAttributes currentRequestAttributes() throws IllegalStateException { RequestAttributes attributes = getRequestAttributes(); if (attributes == null) { if (jsfPresent) { attributes = FacesRequestAttributesFactory.getFacesRequestAttributes(); } if (attributes == null) { throw new IllegalStateException("No thread-bound request found: " + "Are you referring to request attributes outside of an actual web request, " + "or processing a request outside of the originally receiving thread? " + "If you are actually operating within a web request and still receive this message, " + "your code is probably running outside of DispatcherServlet: " + "In this case, use RequestContextListener or RequestContextFilter to expose the current request."); } } return attributes; }}

Spring Boot 创建了 RequestContextHolder 工具类，这个工具类有两个类型为 ThreadLocal 静态成员：

这个工具类提供了以下静态方法：

观察该工具类，可以猜到 Spring Boot 在处理请求时，会通过某种方法 (具体方法后文再涉及) 将当前的请求通过 setRequestAttributes 存入 requestAttributesHolder 中。如果需要获取，就可以通过 getRequestAttributes 将当前请求取出。

那么 setRequestAttributes 的具体过程是什么呢？观察源码：

如果 inheritable 为真，便将 requestAtteributesHolder 的内容清空，向 inheritableRequestAttributesHolder 中存入当前请求；

反之，将 inheritableRequestAtteributesHolder 内容清空，向 requestAttributesHolder 中存入当前请求。

说白了，setRequestAttributes 方法就是将当前请求存入了某个请求属性的持有容器中。

那么，请求属性持有容器的 set 方法又做了什么？

请求属性持有容器是类型为 ThreadLocal 的静态成员，也就是说容器只有一个实例，所有的请求都会被放到这个容器中统一管理。

观察 ThreadLocal 的 set 方法的源码：

注意到，ThreadLocal 的 set 方法本质上是通过当前线程拿到 Map，将 ThreadLocal 作为 key，参数作为 value，存入 Map 中。

那么这个 Map 从哪里来，又属于谁呢？观察 ThreadLocal 的源码：

getMap 本质是返回线程的 threadLocals 成员；

而 createMap 则是为该线程创建了一个 Map。

而 threadLocals，则是每一个 Thread 自带的成员变量，Thread 的源码：

到这里，我们就可以理清关系：

那么，这个 Map——ThreadLocalMap 又是如何实现的？

观察源码：

set 方法的步骤如下：

如果当前下标存放了 Entry：

那么，ThreadLocal 的哈希值从哪里来？nextIndex 又做了什么？

观察源码：

ThreadLocal 类中有一个静态常量 HASH_INCREMENT = 0x61c88647，这个值是斐波那契散列乘数，通过这个常数计算得到的下标的分布相当均匀。

每一个 ThreadLocal 实例创建时，其成员 threadLocalHashCode 即该 ThreadLocal 实例的哈希值，都会通过 静态方法 nextHashCode 生成；

nextHashCode 令静态变量 nextHashCode 增加一个斐波那契散列乘数后返回，AtomicInteger 是一个原子类型，其操作是原子操作，可以保证线程安全。

通过这样的方法，如果依次生成了 3 个 ThreadLocal 实例，他们对应的哈希值就是：

从而使得每个 ThreadLocal 实例拥有唯一的哈希值。

而 nextIndex 其实就是让下标 + 1，如果下标超出当前的长度就返回 0。

可以想象，ThreadLocalMap 的 get 方法其实就是通过当前 ThreadLocal 的哈希值取 (表长度 - 1) 取模算得下标，不断调用 nextIndex 方法直到当前下标存放的 Entry 中的 key 与参数中的 key 一致，则返回 value。

观察源码：

get 方法的步骤如下：

通过当前 ThreadLocal 和 (表长度 - 1) 取模计算得到下标

如果下标对应的 Entry 存放的 key 与 参数中的 key 一致，返回 value

如果不一致或不存在，调用 getEntryAfterMiss 方法

getEntryAfterMiss 判断当前 Entry 是否为空

如果当前 Entry 不为空：

如果存放的 key 与参数中的 key 一致，返回 value

如果参数中的 key 为 null，调用 expungeStaleEntry 方法，清除脏 Entry

如果上述条件不满足，调用 nextIndex 方法计算新的下标

通过新的下标取得当前 Entry，再次判断

最后，请求属性从何而来，Spring Boot 什么时候调用了 RequestContextHolder 工具类中的方法？

Spring MVC 的核心就是 DispatcherServlet 前置控制器，DispatcherServlet 实质也是一个 HttpServlet。DispatcherSevlet 负责将请求分发，所有的请求都有经过它来统一分发。

所有的请求都会经过 DispatcherServlet，而 DispatcherServlet 就会调用 RequestContextHolder 工具类中的方法，存放当前的请求。

DispatcherServlet 继承自 FrameworkServlet ，FrameworkSerlvlet 中的 service、doGet、doPost 等方法都调用了 processRequest 方法：

processRequest 方法中调用 initContextHolders 方法，通过 RequestContextHolder 工具类向请求属性接收容器中存入请求属性：

请求结束后调用 resetContextHolders 方法，通过 RequestContextHolder 工具类恢复之前的请求属性：

这就是 RequestContextHolder 的全过程。